Amazon Auroraのバージョン1.12で高速DDLが実装されました

Guri / Hajime Oguri

2017.04.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

大栗です。

先程Aurora 1.12がアナウンスされました。目玉機能として高速DDLがあるのでご紹介します。

バージョン1.12は必須のアップグレードではありません。バージョン1.12はクラスタの全ノードに対して同時に適用されるクラスタパッチモデルになっていますので、既存のクラスタをアップグレードする場合はご注意下さい。

高速DDL

re:Invent 2016でオンラインDDLの高速化がアナウンスされていましたが、今回のバージョンで実装されました。なお有効化するにはLab Modeを設定（aurora_lab_mode = 1）して下さい。

下表のように通常のMySQLであれば時間がかかるカラム追加でも、Auroraではほぼ一瞬で完了します。大量のレコードがあるテーブルにカラムを追加すると大幅に時間がかかることがあったので、今回のアップデートは大量のデータを保存じているユーザに朗報です。

高速化されるパターン

今回高速化されたDDLはカラム追加となります。以下の形式でDDLを実行します。

ALTER TABLE tbl_name ADD COLUMN col_name column_definition

なお注意点があります。現在のバージョンでは、以下の条件を満たしている場合に高速DDLの対象となるのでご注意下さい。

NULLが可能
デフォルト値が無い
テーブルの最後に追加する

その他のアップデート

Aurora 1.12は他にも新機能があります。

ボリュームステータスの表示

Auroraで使用しているボリュームの状態を確認することができます。Auroraので0他は10GB毎のプロテクショングループに保存されていて、その数の情報となります

mysql> SHOW VOLUME STATUS;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Disks         | 96    |
| Nodes         | 93    |
+---------------+-------+
2 rows in set (0.00 sec)

この機能は、Auroraでディスク障害のシミュレートを行う時に必要となります。ディスク障害のシミュレートを行うクエリではDISK indexやNODE indexを指定する必要があります。今までは各々のインデックスの最大値を特定できなかったのでシミュレートを行うことが大変でしたが、最大値が分かるようになり簡単にテストができるようになりました。

Auroraディスク障害のシミュレートは詳細は以下のリンクのTesting a Disk Failureの項を御覧ください。

Managing an Amazon Aurora DB Cluster » Testing Amazon Aurora Using Fault Injection Queries

改善

ロックオブジェクトの割り当てられたメモリを削減。ラボモードで利用可能です。
アイドル状態で急激にtrx_active_transactionsのメトリクスが減少する問題を修正。
ディスクとノードの障害をシミュレートするクエリに対するエラーメッセージを修正。
ロックマネージャの競合やデッドラッチに関する複数の問題を修正。
クエリオプティマイザのバッファオーバーフローが発生する問題を修正。
ストレージノードで使用可能なメモリが少なくなるとリードレプリカが不安定になる問題を修正。
アイドルコネクションがwait_timeoutパラメータの設定を過ぎても維持される問題を修正。
インスタンスの再起動後にquery_cache_sizeが予期しない値を返す問題を修正。
書き込みがストレージに進んでいない場合に診断スレッドの調査が頻発するパフォーマンスの問題を修正。

バグフィックス

空の削除されたテーブルをリロードするとAUTO_INCREMENTの値がリセットされました。(Bug #21454472, Bug #77743)
purge_node_t構造体の不一致によりロールバック時にインデックスが見つかりませんでした。この不一致により警告とエラーメッセージが表示されました。(Bug #19138298, Bug #70214, Bug #21126772, Bug #21065746)
qsort操作のスタックサイズの計算が正しくないためスタックオーバーフローが発生していました。(Bug #73979)
ロールバック時にインデックスでレコードが見つかりませんでした。(Bug #70214, Bug #72419)
CURRENT_TIMESTAMPの更新時にTIMESTAMPカラムを追加するとZERO-datasが挿入されました。(Bug #17392)

さいごに

Auroraは最大64TBのデータが保存できるので大量のレコードを保持するテーブルがあるユーザも多いことだと思います。MySQLではカラム追加に時間がかかっていましたが大幅に改善されてメンテナンスが楽になりました。他にも幾つかの改善やバグフィックスもされていますので、該当されるユースケースでは適用されると良いと思います。